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ne of the most frequently asked questions about object-oriented 
technology is whether it was used as the primary technology on a 
large project. This question is particularly relevant to Smalltalk 
because it is often said that Smalltalk is a language well-suited for 
prototyping but not for "real” product development. In this arti¬ 
cle we will describe our experience using Objectworks\Smalltalk from ParcPlace 
Systems as the basic implementation language for a commercially available CASE 
tool called ObjecTime. This project is currently in its sixth year and at one point 
involved over 30 Smalltalk programmers. 


THE PRODUCT 

Bell-Northern Research (BNR) designs and develops real-time distributed 
telecommunications systems for its parent company. Northern Telecom. The 
software driving these systems is often surprisingly complex and usually involves 
many millions of lines of high-level code. To meet the extreme quality and ro¬ 
bustness requirements of such systems, it is obvious that powerful computer- 
based development tools are required. ObjecTime (previously known as Telos) is 
one such CASE tool created at BNR for constructing the next generation of dis¬ 
tributed event-driven systems. It can be used for analysis, design, implementation, 
and verification. The tool is a key component of a methodology called Real-Time 
Object-Oriented Modeling (ROOM), which is characterized by a set of high-level 
design paradigms and a highly iterative development process. 1 With ObjecTime, 
users graphically capture the high-level aspects of their designs and combine them 
with specifications written in C++, or a simple rapid prototyping language for the 
more detailed aspects. These designs can be executed directly using ObjecTime’s 
built-in run-time environment. ObjecTime is currently the most widespread 
CASE tool within BNR. It has been made available to external (non-BNR) cus¬ 
tomers and has already been purchased by several major corporations. 

The software comprising the tool is quite elaborate and includes an interactive 
graphical user interface, several complex semantic editors, a high-level language 
compiler, and an event-driven run-time system. This system’s level of complexity 
can be deduced from the size of the class hierarchy, which currently contains close 
to 1,400 Smalltalk classes. 

THE PROJECT AND ITS CHRONOLOGY 

The project has so far progressed through three principal stages: a prototyping 
stage, a development stage, and a commercial product stage. 

The prototyping stage 

The prototyping stage started in late 1986 and lasted approximately 18 months, 
during which time the project team grew from three to 18 people. None of the 
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H APPY ANNIVERSARY! We thought somebody should say it, as we roll into year two of 
The Smalltalk Report. We trust you have been satisfied with the quality of articles over 
the past 12 months. Subscriptions are constantly climbing, as is the number and diversity 
of Smalltalk users. We have tried to include articles that have a broad band of appeal yet 
are specific enough to give you more than just a “warm feeling.” Certainly the best part of 
this job has been the opportunity to meet many of you (albeit electronically in most 
cases!!)- Please, keep coming forward with ideas. 

As you are all aware, one requirement sorely lacking in our niche of the software in¬ 
dustry is a repository of documented experience reports. Other than OOPSLA’s experi¬ 
ence reports, very little is available in terms of actual documented case studies. Newcom¬ 
ers to object-oriented technology, and Smalltalk in particular, want to see proof that the 
technology has been successful. And those of you trying to get on with the development of 
software know how much easier life would be with a reservoir of experiences from previ¬ 
ous projects, both good and bad, on which to draw. If you’re like us, you’re constantly left 
with the feeling that “this has been done before,” especially in terms of adapting tradi¬ 
tional management strategies to Smalltalk projects. It’s time we started to reuse more than 
just code. 

Bran Selic’s feature article describes many experiences gained during the development 
of the CASE tool ObjecTime at Bell Northern Research. He gives a chronology of the pro¬ 
ject, highlighting things that worked well and some of the ptifalis encountered. 

Also in this issue, Dan Benson concludes his three-part series on the development of 
SmallDraw, his graphics editor, illustrating the “ins and outs” of MVC. He adds facilities 
to SmallDraw to allow grouping, layering, and alignment of objects, cut/copy/paste facili¬ 
ties, and scrolling. 

Three of our regular columns appear this month with each building on themes de¬ 
veloped in earlier columns. Kent Beck’s column describes the inherent shortcomings of 
the change propagation mechanism and describes the ValueModel style of coding intro¬ 
duced in Objectworks\Smalltalk 4.0. Juanita Ewing continues her discussion of proper 
use of inheritance through an example of adding an OrderedSet to the Collection hierar¬ 
chy. Finally, Alan Knight continues his survey of many of the complaints registered on 
USENET about OOP. 

In closing, we would like to take the opportunity to thank those of you who have 
helped us out over the past year. A special thanks goes to our regular columnists, who 
have yet to let us down and whose contributions form the pillar of the Report. 

Thanks, gang! 
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The Management Challenge 

The transition to object technology 
must be designed for success. The 
management challenge is to: 

• Produce Quality Software 

• Deliver on Time 

• Build Maintainable Code 

• Model the Business Problem 

• Build Client-Server Solutions 

• Manage Complexity 

Knowledge Systems Meets 
the Challenge 

Knowledge Systems Corporation 
(KSC) has emerged as the industry 
leader in delivering pure object- 
oriented product solutions. KSC 
products and services are designed to 
successfully transition business to 
object technology. 


Transition Services 

KSC Transition Services include 
contract services and a complete 
training curriculum that supports a 
group development environment. 
Multiple training tracks are designed 
to ultimately attain self-sufficiency 
and to produce deliverable solu¬ 
tions. Program curriculum includes: 

• Mentoring: Process Support 

• Apprentice: Small Group Project 

Focus at KSC 

• Finding the Objects (CRC) 

• 00 Analysis and Design 

• Introductory to Advanced 

Programming in Smalltalk 

• Introduction to Smalltalk for 

COBOL Programmers 


Development Environment 

KSC now markets in the U.S. and 
fully supports ENVY™/Developer, a 
multi-user development environ¬ 
ment. In addition, KSC provides 
integrated services and tools to 
enable construction of cooperative 
processing applications. 

Design your Transition 

Begin your successful transition to 
object technology today. Join the 
growing list of KSC clients such as 
IBM, Hewlett-Packard, Texaco, 
Fisher Controls, American Airlines, 
First Union, Northern Telecom, and 
Texas Instruments. For more infor¬ 
mation on transition products and 
services from Knowledge Systems, 
call us at 919-481-4000. 



Knowledge Systems Corporation 

OBJECT TRANSITION BY DESIGN 


© 1992 Knowledge Systems Corporation. ENVY is a trademark of Object Technology International, Inc. 


114 MacKenan Dr. 
Cary, NC 27511 
(919) 481-4000 
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... continued from page 1 

team members had practical experience with 0-0 technology 
but we decided to adopt an 0-0 approach. 

Communications software traditionally has been designed 
using an object-based approach, primarily because of the in¬ 
herently distributed and asynchronous nature of communica¬ 
tions systems. We were looking for a new technology that 
could overcome some of the major limitations of traditional 
software construction methods. 

After some deliberation, we chose Smalltalk as the imple¬ 
mentation language for our prototyping. Various object- 
oriented flavors of C (Objective C, C++) were also considered 
and discarded. We felt that a qualitatively different technology 
was required to deal with the complexity we had forecast for 
the coming generation of software systems. We were interested 
in programming abstractions that could deal with entire sub¬ 
system architectures and complex graphics. The semantic gap 
between these and the low-level machine-oriented abstractions 
provided in C and similar languages was just too great. 

We originally selected Smalltalk/V from Digjtalk Inc. After 
about a year, we switched to Smalltalk-80 from ParcPlace Sys¬ 
tems because ParcPlace software ran on the Unix-based work¬ 
stations used by most of our client base. In addition, our own 
performance benchmarks indicated that at that time (late 
1987), our application would execute more than twice as fast 
on ParcPlace Smalltalk than on Small talk/V on the same plat¬ 
form. The port of our code to Smalltalk-80 was straightfor¬ 
ward with most of the difficulties stemming from differences in 
the graphics paradigms. 

There was no formal design process but the issue was dis¬ 
cussed at length, with great fervor and some dissent. The 
highly interactive Smalltalk development environment was un¬ 
like any the team had experienced before. It obviously had 
great potential that was not exploited fully by traditional linear 
models of software development. 

Our initial development consisted of a set of disjoint proto¬ 
types of different toolset components, each one designed and 
implemented by a single developer. In the latter part of the 
prototyping stage the distinct components were integrated, 
one-by-one, into a composite whose functionality roughly ap¬ 
proximated that of the desired system. There were no commer¬ 
cially available team programming environments at that time 
so we eventually evolved a “manual” process for synchronizing 
the activities of programming teams. 

This process was based on a weekly integration cycle. At the 
beginning of each week a new version of the system was gener¬ 
ated by the system integrator. Once this image was available, 
designers would copy it to their own environment and make 
further changes to it as necessary. At the end of the week, de¬ 
signers would submit their changes for inclusion in next week’s 
image. To minimize conflicts, all the classes in the hierarchy 
were partitioned so that each class was owned by a group. Only 
members of the group owning a class were allowed to submit 
changes for that class. Also, it was possible to specify the inte¬ 
gration order of a submission relative to other submissions. A 
common “patches” repository was maintained fbr any changes 


that needed to be shared in the interval between successive in¬ 
tegrations. These could be tilled in at the discretion of the indi¬ 
vidual developer. 

To our surprise, we found that this manual process was ef¬ 
fective even in later stages of the project when the development 
team was much larger. We attributed this to the decoupling ef¬ 
fect of partitioning the class hierarchy across different groups 
as well as to the highly modular and loosely coupled architec¬ 
ture of the application. 

The development stage 

Following our prototyping experience we commenced the ac¬ 
tual implementation in September of 1988. This second stage 
lasted approximately two years. During that time the internal 
architecture of the tool was reorganized and almost all of the 
prototype code rewritten. The development team doubled in 
size to eventually include over 30 developers (not including 
managers), all of them programming in Smalltalk. 

The software was developed gradually, in four successive 
releases, each release extending the capabilities of the previous 
one. One of those releases included porting of the complete 
software from a Macintosh platform to a Unix workstation 
(Sun Microsystems SPARCstation 1). This porting effort 
turned out to be trivial despite significant differences between 
the underlying hardware and operating systems. The ease with 
which this was accomplished confirmed the portability claim 
of the ParcPlace Systems ObjectworksVSmalltalk product. 

A more formal development process was used during this 
stage since we were working on a production version of the 
software and a much larger team was involved. The final ver¬ 
sion of this process is described in a later section. 

The commercial product stage 

Until the end of 1990 ObjecTime was exclusively targeted to 
internal BNR projects. In 1991 the potential for more 
widespread use was recognized and a decision was made to 
market the technology. This meant setting up a full-fledged 
support organization, “robustification” of the software to com¬ 
mercial-quality standards, creation of high-quality user docu¬ 
mentation, and functional extension with features required by 
a much wider open market. With basic toolset architecture and 
functionality in place this was accomplished by a smaller and 
more focused team. 

The current release of the toolset, ObjecTime Release 4.0, 
contains close to 1,400 classes and the initial image requires 5.8 
MB. Despite these relatively large numbers, we have not yet 
encountered nor do we anticipate any fundamental technical 
or resource limitations of either the language or the ParcPlace 
ObjectworksVSmalltalk environment. 

EXPERIENCE WITH SMALLTALX 

This section summarizes some of the salient aspects of our 
Smalltalk experience. 

continued on page 6... 
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10 Ifears Ago, 
When OTI Sugges 
That Object-Oriented 
Technology Would 
Revolutionize 
The Software Industry, 
People Called Us 
Crazy... 


Now, They Simply Call Us. 


For over 10 years, Oil has been on the 
leading edge of object-oriented software 
engineering. And today, as more and more 
companies adopt this exciting, new 
technology, OTI remains the leader in 
providing industrial and commercial 
object-oriented solutions. 

Partners in 

Object-Oriented Development 
OTI’s unique technology alliance program 
provides a means of accelerating product 
development and introducing new software 
technology. OTI’s technology is being used 
in products ranging from pen computers to 
real-time systems. Through these alliances, 
we've earned a solid reputation for developing 
high-quality, reliable software - on-time, 
within budget and to demanding product 
specifications. This success is attributed to 


OTI’s ENVY ^/Developer - the first multi-user 
development environment for object-oriented 
engineering. 

OTI’s ENVY/Developer - Product 
Development Tools For Smalltalk 
With ENVY /Developer, large and small 
software engineering teams work within an 
interactive, shared programming environment. 
Inside this environment, team members share 
common development tools, common software 
components and common source code - that 
means faster cycle times, increased productivity, 
virtually no duplicated code, and no wasted 
effort. 

Applications are created efficiently and 
effectively, from beginning to end. Using 
ENVY /Developer, the team passes the 
application through each phase of the software 


manufacturing lifecycle - conceptualizing, 
prototyping, manufacturing, testing, release 
and maintenance - without ever leaving the 
environment. ENVY /Developer also tracks 
this process by providing complete software 
version control and multi-platform 
configuration management. 

Interested? 

If your organization is interested in joint 
research and development or you would like 
more information on ENVY /Developer and 
object-oriented programming environments, 
call us today. 

Object technology 
International Inc. 

Engineering Ideas 
Into Products 



Canada Telephone: 613-820-1200 • Fax: 613-820-1202 • E-mail: info@oli.on.ca USA Telephone: 602-222-9519 • Fax: 602-222-8503 
ENVY is a registered trademark of Object Technology International Inc. 
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Productivity 

We are convinced that Smalltalk, with its sophisticated and 
customizable environment, source-level debugging capabil¬ 
ity, extensive class library, and automated storage reclama¬ 
tion, is significantly more productive than most other devel¬ 
opment environments (including, to a lesser degree, other 
0-0 environments). 

This is substantiated to a certain extent by an interesting 
case that occurred during the project. As part of our develop¬ 
ment we were required to implement a general purpose graph¬ 
ical windowing system using ObjectworkslSmalltalk. Simulta¬ 
neously, a second development group was independendy 
implementing a similar facility in C based on an X Window 
System toolkit. This substantial application amounted to ap¬ 
proximately 66,000 lines of C code, while the same functional¬ 
ity in Smalltalk required only 6,200 lines of Smalltalk—a func¬ 
tionality ratio of 10 to 1 per line of code! A more conservative 
estimate, based partly on these results and partly on our overall 
experience on this project, is that Smalltalk gave us a produc¬ 
tivity advantage three to five times over a traditional program¬ 
ming language such as C. 

We believe that Smalltalk has a significant productivity edge 
over other 0-0 languages as well. Although we have no hard 
quantitative data, our rough estimate is that Smalltalk is at 
least two to three times more productive than C++. 

Performance 

ObjecTime is a computing-intensive application: It has a 
graphical interactive user interface, it must perform complex 
semantic checks in real time, and it must efficiendy execute 
complex high-level designs. By far the greatest portion of this 
functionality is implemented in Smalltalk. (Lesser portions 
[approximately 5%] were implemented in C++, not for perfor¬ 
mance reasons, but to enable execution of the C++ segments of 
a user’s design.) Although we occasionally encountered perfor¬ 
mance problems, in most cases we were able to improve per¬ 
formance to acceptable levels either via straightforward code 
optimization or through readjustment of the architecture. 

The only potentially serious problem relating to performance 
is an occasional pause for memory compaction, which is part of 
the automatic garbage collection mechanism. For our applica¬ 
tion, we found that this pause becomes unacceptable in situa¬ 
tions where there is not enough real memory so part of the 
garbage collection involves swapping memory from disk. To 
eliminate this problem we stipulated a minimum amount of real 
memory for our application. Memory requirement is a function 
of the size of the user design. For ObjecTime release 3.5.1, mini¬ 
mal memory requirement starts at 16 MB (on a Unix worksta¬ 
tion) for small to intermediate designs and goes up to 40 MB for 
the largest designs. With sufficient memory in place, the garbage 
collection pause is relatively short (between 4 and 10 seconds) 
and occurs infrequently (every 15-20 minutes). 

Quality 

Most of our development was done with the ParcPlace Systems 


product, Objectworks\Smalltalk (from release 2.1 through release 
2.5). In over four years we encountered only two problems, both 
minor, which required product fixes by the vendor. 

Usability for large system development 

Our experience demonstrated that Smalltalk was a practical so¬ 
lution for moderately large development teams (30 program¬ 
mers) even without the assistance of specialized team pro¬ 
gramming tools. Of course, if such tools are available (e.g., 
ENVY/Developer from Object Technology International), they 
should be used, since they add significant value and can extend 
the applicability of Smalltalk to even larger projects than ours. 

Training 

Carleton University is one of the major world centers of 
Smalltalk expertise. The School of Computer Science at Car¬ 
leton organized a short course, taught by professors John 
Pugh, Wilf LaLonde, and Dave Thomas, which for most team 
members was the initial exposure to Smalltalk. We were also 
able to hire, on a temporary basis, a group of graduate and un¬ 
dergraduate students who served as consultants on proper 
Smalltalk usage. The presence of such experienced Smalltalk 
programmers significantly cut down on our training time. 

In addition to the Carleton course, we took an “intermedi¬ 
ate” level Smalltalk course offered by ParcPlace Systems, which 
focused on common techniques for effective usage of the envi¬ 
ronment. This course visibly increased the confidence level of 
the development team. 

It takes between one and three weeks for an experienced pro¬ 
grammer to leam enough Smalltalk to start using it on the job. 
However, for a programmer to effectively use Smalltalk, it is 
necessary to become familiar with the 0-0 paradigm, the class 
library, and the programming environment itself. In our experi¬ 
ence the majority of programmers needs an additional 6 to 20 
weeks to reach an “intermediate” level of proficiency. (Keep in 
mind that the same amount of time is needed to leam the envi¬ 
ronmental particulars [e.g., code libraries] for any large project.) 

The development process 

Our development process differed somewhat from the tradi¬ 
tional model. First of all, we wanted to take advantage of the 
rapid prototyping capability of Smalltalk. Proper use of this 
feature helps designers gain valuable insight early in the devel¬ 
opment cycle and before major implementation effort is ex¬ 
pended. Inheritance also adds a new aspect to the overall de¬ 
sign effort. Typically this requires additional effort consisting 
of another pass through the design after the desired functional¬ 
ity is fully achieved. Further design optimization is accom¬ 
plished from the perspectives of reuse and abstraction. We ul¬ 
timately settled on a process consisting of four main activities: 

1. Functional design defines the functionality of the feature 
being developed. The output of this activity is a Functional 
Specification document which can be discussed with 
clients. Once finalized, this specification is also given to an 
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independent verification group to allow early preparation 
of test plans. 

2. Object or class design is the fundamental synthesis process in 
which a high-level design is worked out for the feature. If 
the feature is complex enough, a formal Design Document 
is produced for review purposes. 

3. Coding is part of the prototyping and refinement activity. In 
the case of prototyping, this activity is often concurrent 
with and supplemental to class design and even functional 
design. Given the importance of user interfaces to our ap¬ 
plication, a distinct subactivity is early modeling and evalu¬ 
ation of the user interface design. 

4. Documentation and testing are usually done in the final 
stage. Each designer generates a functional test plan that is 
reviewed and used for white box testing. For major features, 
code inspections are also held. This phase also includes test¬ 
ing of the software by an independent verification group. 

Although the individual activities are listed in sequence, the 
process allows for internal cycles to accomodate further refine¬ 
ments, particularly following implementation. 

The project management process 

The iterative nature of the development process makes it 
difficult to detect whether or not it converges. To get around 
this we specified a linear progression of milestones, each one 
tied to a concrete deliverable. The interval between successive 
milestones was fixed in advance, based on a priori estimates of 
the effort required. For example, the formal release of a Func¬ 
tional Design document was the first milestone following the 
start of feature development. Other major milestones included 
the release of an Object Design document, the delivery of code 
to a test group, and the successful completion of testing. Not 
surprisingly, we had the most difficulty estimating the amount 
of effort needed for individual milestones to be achieved. This 
was especially problematic at the beginning because we had 
had no previous experience with an iterative development pro¬ 
cess or the 0-0 paradigm. 

Additional observations 

To conclude this summary of our experience, we list several 
additional points pertaining to 0-0 development: 

1. The management team must have an in-depth understand¬ 
ing of 0-0 technology to gain maximum return from it. 
This technology is different enough from traditional ones 
(e.g., the focus on reuse, iterative development process) that 
many of the long-established management practices are in¬ 
appropriate. Because this is a relatively new technology not 
many technical managers are experienced with it. 

2. There is a significant need to develop better management met¬ 
rics to reconcile an iterative development process with the 
needs of management so that a process stays within its allocated 
resources. Successive refinement can indeed reach a point of di- 


Juet opened! 

The first online Smalltalk marketplace where 
any developer can sell or buy Smalltalk tools, 
components, add-one, advice or training, and 
hook up with the right people. If you’re looking 
for the beet in Smalltalk, come to the AMIX 
online marketplace. 

We’re offering the AMIX eoftware for free. 
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minishing returns. How do we detect when that point has been 
reached? New metrics are also required to measure productiv¬ 
ity, with refinement, the number of lines of code can actually 
decrease with time through inheritance and reuse. 

3. The ease and rapidity with which code can be changed and re¬ 
compiled in Smalltalk can easily lead to hacking with little or 
no time taken to reflect. (Smalltalk is one of those seductive 
environments where it is very easy for the medium to become 
the message.) This style of development tends to work bottom 
up and does not extend very well to large system design. The 
best way to avoid this is to ensure that a system architecture is 
defined before any development of details takes place. 

CONCLUSION 

We have been using Smalltalk on our project for almost six 
years; overall, our experience remains strongly positive. We 
have confirmed not only that Smalltalk is powerful and robust 
enough to be used for commercial-quality software, but also 
that there are substantial benefits when compared with other 
implementation options. Finally, we have demonstrated that 
Smalltalk can be used successfully on large and long-term pro¬ 
jects involving sizable programming teams. ■ 
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Small Draw — 
release 4 

GRAPHICS AND 

MVC, Part 3 

Dan Benson 

maUDraw is a simple structured graphics editor 
that provides an example of graphics rendering 
and MVC application construction in Smalltalk- 
_80 Release 4. The first article in this series con¬ 
tained an introduction to graphics concepts and application 
construction with the MVC architecture through the definition 
of a “minimal” SmallDraw. The second article added the abil¬ 
ity to select and modify objects in the view. This third and final 
article extends the features of SmallDraw to include grouping 
of objects, layering of objects, alignment of objects through a 
Dialog View, cut/copy/paste operations through a shared clip¬ 
board, the use of command keys, and scrolling of the view. In¬ 
formation on obtaining the complete source code for Small¬ 
Draw is given at the end of the article. 

GROUPING OBJECTS 

Grouping objects together allows them to be treated as a single 
unit. That is, a grouped collection of objects can be translated, 
scaled, and copied as a single object. To do this, a new class is 
defined as a subclass of SDGraphicObject, called SDGraphicGroup: 

Object () 

SDGraphicObject ('insideColor' 'borderColor' TineWidth' 'handles' 
'boundingBox') 

SDGraphicGroup ('elements') 

SDGraphicGroup’s single attribute, elements, holds a collec¬ 
tion of SDGraphicObjects. It implements specific methods for 
calculating its boundingBox, displaying its elements, testing for 
point inclusion, and translation and scaling. For example, SD- 
GraphicGroup defines the following method for translation: 

tranilateJBy: afolnt 

self elements do: [:o | o translateBy: aPoint], 
self computeBoundingBox 

The SmallDraw model is responsible for grouping objects. 
When the group operation is selected from the menu, Small¬ 


Draw creates a new SDGraphicGroup, setting its elements to the 
currently selected set of objects. The selected objects are re¬ 
moved from SmallDraw’s objects and the new SDGraphicGroup is 
added to SmallDraw’s set of objects. 

The inverse operation of un- grouping is also provided. 
When this operation is selected, SmallDraw removes any in¬ 
stances of SDGraphicGroup from the current selection, adding 
each individual element to its set of objects. 

LAYERING OBJECTS 

As objects are added to the drawing they are placed on top of 
existing objects; that is, they are conceptually layered. This idea 
is also reflected exactly in the SmallDraw objects instance vari¬ 
able as an OrderedCollection of objects. 

It is often useful to change the relative positioning of objects 
within the stack. This is accomplished by providing four menu 
selections, shown in Figure 1, for moving objects to the front or 
back of the stack, or forward or backward by one position. 


new 


!_ 


forward (alt-f) 

edit 

> 

group (alt-g) 

to front 

change 

i> 

ungroup (alt-G) 

backward (alt-j) 

display 

s> 

align (alt-k) 

to back 


alignment... 



Figure I. Menu selection for moving objects. 

Moving selected objects to the front is done by simply re¬ 
moving them from the list of objects and adding them to the 
front of the list: 

moveToFront 

self hasSelection ifTrue: [ | selection | 

selection := self selectedObjectAssodations. 
selection do: [:oa | self objects remove: oaj. 
self objects addAUFirsfc selection. 

self changed: #rectangle with: self selectedObjectsDisplayBox] 

Moving objects forward by one position is done by insert¬ 
ing the selected object before the object that was in front of it: 

moveForward 

self hasSelection ifTrue: [ 

self selectedObjectAssodations do: [:oa | | before ) 
self objects first = oa 

iffalse: [before := self objects before: oa. 
self objects remove: oa. 
self objects add: oa before: before]], 
self changed: #rectangle with: self selectedObjectsDisplayBox] 

Moving objects to the back or backward one position is 
done in a similar fashion. 
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ALIGNING OBJECTS 

A difficult and time-consuming task in any graphics editor is 
trying to get objects aligned with each other. Confining the 
mouse to a low-resolution grid is helpful but not always ade¬ 
quate. This task can be simplified with the use of a Dialog View 
to specify the type of alignment desired. Alignment can take 
place in either of two directions and one of three positions for 
each direction (see Figure 2). 

The user has the option of choosing one or both directions. 
For each direction, only one position can be specified using the 



Figure 2 . Alignment Dialogview. 


radio buttons. The chosen alignment positions are retained by 
SmallDraw so that they may be applied to selected objects with¬ 
out bringing up the DialogView each time. Therefore, two menu 
selections are added, one for applying the current alignment 
and one for setting the stored alignment. 

When the alignment is to be set, SmallDraw creates a Di- 
alogView whose model is SmallDraw. When the DialogView is 
opened, SmallDraw specifies a message selector (#finishedAlign- 
ment) that determines when the view should be closed. Until 
that message selector returns true, the DialogView interacts with 
the user and SmallDraw to set and modify the alignment direc¬ 
tions and positions. 

The vertical and horizontal positions are represented as 
symbols. These values are stored along with a flag that indi¬ 
cates whether Cancel or OK was pressed in the DialogView. 
Rather than adding three new instance variables to SmallDraw, a 
single instance variable called alignment is added. This is an in¬ 
stance of a three element Array to store the three pieces of in¬ 
formation as follows: 

inltjallTf Alignment 

The alignment instance variable is an array of three elements: 

1) vertical alignment ( nil 

2) horizontal alignment ] nil 

3) false | true | nil -> cancel | accept [ not finished (used by 

DialogView) 
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The last flag must be set to nil each time the DialogView is opened. 
See openAlignmentDialog and finishedAlignment." 
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alignment isNil 

ifTme: [alignment := Array with: nil with: nil with: nil], 
alignment at: 3 put: nil 

Methods are used to access the alignment array elements as 
follows: 

acceptAllg ament 

alignment at: 3 put: true 
acceptedAligiunent 
"alignment at: 3 
cancelAUgnment 

alignment at: 3 put: false 
finlshedAlignment 

"(alignment at: 3) notNil 
horiz ontalAlig rune nt 
"alignment at: 2 
horizontalAlignment aSymbol 
alignment at 2 put: aSymbol. 
self changed: #horizontalAlignment 
verticalAllgiunent 
"alignment at: 1 
verticalAlignment: aSymbol 
alignment at: 1 put: aSymbol. 
self changed: #verticalAlignment 

Alignment is performed relative to the total boundingBox of 
the currently selected set of objects: 

doAUgnment 

self hasSelection ifTrue: [| bb repair | 
bb := self selectedObjectsBoundingfiox. 
repair := self selectedObjectsDisplayBox. 

"Vertical movement." 

self verticalAlignment = #top ifTrue: [ 

self selectedObjects do: [:o | o translateBy: 

0@(bb origin y - o boundingBox origin y)JJ. 
self verticalAlignment = #center iflhie:[ 

self selectedObjects do: [:o | o translateBy: 

0@(bb center y - o boundingBox center y)]]. 
self verticalAlignment = #bottom ifTrue; [ 
self selectedObjects do: [:o | o translateBy: 

0@(bb comery- o boundingBox comer y)]]. 

'Horizontal movement." 

self horizontalAlignment ■ #left ifTrue: [ 

self selectedObjects do: [:o | o translateBy: 

(bb origin x - o boundingBox origin x) @0]]. 
self horizontalAlignment 3 #center ifTrue: [ 
self selectedObjects do: [:o [ o translateBy: 

(bb center x - o boundingBox center x) @0]]. 
self horizontalAlignment = #right ifTrue: [ 
self selectedObjects do; [:o [ o translateBy: 

(bb comer x - o boundingBox comer x) @0]]. 
self changed: #rectangle with: repair] 


CUT/COPY/PASTE 

A common metaphor in many applications is the cutting, 
copying, and pasting of objects using a “clipboard” as an inter¬ 
mediate storage mechanism. The Macintosh system is an excel¬ 
lent example of using a common system clipboard to transfer a 
variety of data objects between applications. Similarly, graphic 
objects can be copied or cut to a common buffer accessed by 
all SmallDraw applications. 


Intermediate storage implies an instance variable that can 
reference collections of graphic objects. Sharing access to this 
storage among SmallDraw instances suggests that a SmallDraw 
class variable is the appropriate mechanism for a common 
clipboard. Therefore, a class variable called Clipboard is added 
to the SmallDraw class. The Clipboard can hold one object, or 
one collection of objects, at a time. Copy and cut operations 
are destructive because they overwrite the current contents of 
the Clipboard. Pasting is nondestructive because a copy is made 
of the Clipboard contents and added to the drawing. 

It may seem trivial to implement the copy operation by 
simply assigning the Clipboard class variable to a copy of the se¬ 
lected objects: 

copy 

self hasSelection 

ifTrue: [Clipboard := self selectedObjects copy] 

However, care must be taken when copying and pasting ob¬ 
jects to and from the Clipboard. The Smalltalk copy performs a 
shallow copy, which simply duplicates references to the objects 
to be copied (making them identical and thus equal), and the 
Clipboard then points to the objects remaining in the drawing. 
In contrast, a deepCopy creates exact duplicate objects that are 
different from the originals (equal but not identical): 

copy 

self hasSelection 

ifTrue: [Clipboard := self selectedObjects deepCopy] 

It is not necessary to use deepCopy when objects are cut 
from the drawing. In this case, the objects are removed from 
the drawing and essentially transferred to the Clipboard: 

cat 

self hasSelection ifTrue: [ 

Clipboard := self selectedObjects. 

self objects: (self objects reject: [:p | p value]). 

self changed: #rectangle with: self clipboardDisplayBox] 

When objects are copied to the Clipboard, they retain their 
attributes including their location in the drawing. A copied ob¬ 
ject immediately pasted back into the drawing covers its origi¬ 
nal copy. A useful convention is to paste an object into the 
drawing at an offset from its copied position. Each subsequent 
paste of the same object would then be offset from the previ¬ 
ous pasted object. This can be accomplished by defining a 
paste offset constant and translating the contents of the Clip¬ 
board with each paste operation: 

pasteOffset 

'Answer the default offset for pasting objects from their copied 
positions." 

" 10@10 

paste 

self clipboardFull ifTrue: [ 
self deselectAU. 

self objects addAUFirst: ((Clipboard do; [:o | 
o translateBy: self pasteOffset]) 

deepCopy collect: [:o | o -> true]). 
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WindowBuilder 

The Interface Builder for Smalltalk/V 
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The key to a good application is its user interface, and 
the key to good interfaces is a powerful user interface 
development tool. 

For Smalltalk, that tool is WindowBuilder. 

Instead of tediously hand coding window definitions and 
rummaging through manuals, you'll simply “draw” your 
windows, and WindowBuilder will generate the code for 
you. Don't worry — you won't be locked into that first, 
inevitably less-than-perfect design; WindowBuilder 
allows you to revise your windows incrementally. Nor will 
you be forced to learn a new paradigm; WindowBuilder 
generates standard Smalltalk code, and fits as seamlessly 
into the Smalltalk environment as the class hierarchy 
browser or the debugger. 

Our new WindowBuilder/V Windows 2.0 is now available 
for $149.95, and WindowBuilder/V PM is $295. Both 
products include Cooper & Peters' unconditional 60 day 
guarantee. 


this is a potent rapid application development tool which For a free brochure, call us at (415) 855-9036, or send us a 

should be included in any Smalltalk/V developer's environment.” fax at (415) 855-9856. You’ll be glad you did! 

- Jim Salmons, The Smalltalk Report , September 1991 

Cooper & Peter*, Inc. (formerly Acumen Software) 2600 Ei Canino Real, Suite 609 Palo Alto, California 94306 Phone 415 855 9036 Fax 415 B55 9856 CompuServe 71571,407 


self changed: #rectangle with: self clipboardDisplayBox] 

Note that all pasted objects become the current selection by 
setting the value part of the Association to true. Making dupli¬ 
cates of objects can be simplified by defining a duplicate opera¬ 
tion that bypasses the Clipboard: 

duplicate 

"Add a copy of the current selection without changing the Clipboard." 
self hasSelection ifTrue: [ | newObjects | 

newObjects := (self selectedObjectAssoriations deepCopy do: [:oa j 
oa key translateBy: self pasteOffeet]). 
self deselectAll. 

self objects addAllfirst: newObjects. 

self changed: #rectangle with: self selectedObjectsDisptayBox] 

COMMAND KEYS 

As an input device, the mouse is a convenient mechanism when 
working with modem bit-mapped graphical user interfaces. 
However, it is often faster and less tiring to perform a com¬ 
mand via the keyboard than to make a selection from a menu. 

Keyboard commands are distinguished from normal typing 
by pressing a combination of two keys: the command key and 


a letter key. The command key looks like on the Macintosh 
and is the alt key on the IBM RS/6000. Other platforms may 
vary. The Smalltalk class InputSensor refers to the command 
keys as alt or meta (depending on the platform) and responds 
when either is pressed through the messages altDown and meta- 
Down, respectively. 

Command key equivalents can be defined for most of the 
operations that SmallDraw performs. Borrowing from a popular 
commercial structured graphics application, the following keys 
are used to invoke the following operations: 


key 

operation 

X 

cut 

c 

copy 

V 

paste 

f 

move forward 

j 

move backward 

d 

duplicate 

a 

select all 

k 

align 

9 

group 

G 

un-group 
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46 

[In SmallDraw] the controller is 
independent of command key processing 
and additional keys may be added 
to the model without changing the 
controller’s method. 


The SmallDrawController is responsible for all input, and can 
now check for keyboard activity in its normal control se¬ 
quence. All of the operations listed above are performed by the 
SmallDraw model. When the controller senses that a command 
key has been pressed, it forwards the key to the model for pro¬ 
cessing. This way, the controller is independent of command 
key processing and additional keys may be added to the model 
without changing the controller’s method. The SmallDraw in¬ 
stance method that processes command keys looks very much 
like the list of operations above: 

proceuCommandKey: aKey 

"Respond to aKey which may correspond to one of the receiver's 
menu commands. If not. ignore it." 
aKey - Oiaracter backspace ifTrue: [self delete]. 
aKey - )x ifTrue: [self cut]. 
aKey-Jc ifTrue: [self copy]. 
aKey - |v ifTrue: [self paste]. 
aKey- SfifTrue: [self moveForward]. 
aKey - $J ifTrue: [self moveBackward], 
aKey - $d ifTrue: [self duplicate], 
aKey - $a ifTrue: [self selectAU]. 
aKey - Jk ifTrue: [self do Alignment], 
aKey - Jg ifTrue: [self group]. 
aKey - JG ifTrue: [self unGroup], 

SmallDraw menus are modified to indicate the keyboard com¬ 
mands that may substitute for menu operations (see Figure 3): 

SmallDrawController is only slightly modified in order to han¬ 
dle keyboard events. One method is added to detect and pro¬ 
cess any keyboard activity: 


new 



[selection > 


cut 

(alt-x) 

change 

> 

copy 

(alt-c) 

display 

» 

paste 

(alt-v) 



duplicate 

(alt-d) 



select all 

(alt-a) 


proofasKeyboaid 

"Determine whether the user pressed the keyboard. If so, read the 
key and pass it on to the model." 
self sensor keyboardPressed ifTrue: [| keyHit | 

KeyHit:- self sensor keyboardEvent keyValue. 

‘Check for backspace here." 
keyHit - Character backspace ifTrue: . 

[self model process Co mm andKey: keyHit]. 

(self sensor attDown or [self sensor metaDown]) ifTrue: [ 
"KeyValues are lowercase so we must convert to uppercase if the 
shift key is down." 
self sensor shiftDown ifTrue: 

[keyHit:- keyHit aslfppercase]. 
self model proce ss CommandKey: keyHit]] 

and one inherited method is overwritten to include the key¬ 
board method in its control loop: 

controlActlvtty 

"First check the keyboard and then do the usual." 
self processKeyboard. 
super contralActivity. 


SCROLLING THE VIEW 

SmallDrawView can become a scrollable view by defining it as a 
subclass of ScrollingView. The class comments for ScrollingView 
include the following information: 

Subclasses must implement the following messages: 
accessing 

displayObject 

scrolling 

scrollBy: 

scrollHorizontalty: 

soollVerticaUy: 

DisplayObject must be able to respond to the message bounds. 
DisplayObject is the object being scrolled in the view, in this case 
tile SmallDraw drawing. SmallDrawView needs to know how big 
the SmallDraw document is so that the scroll bars can be prop¬ 
erly scaled. SmallDraw’s new instance variable, pages, is an in¬ 
stance of a Point that defines the number of pages lined up hor¬ 
izontally and vertically. The minimum is 1@1, or one page. For 
two pages side by side, pages would be 2@1, and so on. The 
document automatically increases in pages if objects are trans¬ 
lated or scaled such that they extend beyond the rightmost or 
bottommost pages of the document The SmallDrawController 
ensures that objects are not allowed to extend beyond the left¬ 
most or topmost pages. 

The size of the document is obtained by asking SmallDraw 
for its bounds: 

bo and* 

A 0@0 extent: self documentSize 

where the page configuration is converted to pixels by multi¬ 
plying an 8 1/2 x 11 inch sheet of paper (assuming 1/2 inch 
margins all around) by the number of pixels per inch: 

documentSize 

"Answer the size of the document in terns of the number of 8.5 x 
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11 inch pages." 

A self pages ' self pageSizelnPixels 

pageSizelnPlxels 

"Answer the size of one 8.5 x 11 inch page (with 1/2 inch margins), 
scaled fay the number of pixels per inch (72). This number is 
calculated as: ((7.5(310) * 72) rounded." 

A 540@720 

To ensure proper scaling of the scrolled object, Small- 
DrawView defines the following method: 

dataExtent 

A self displayObject bounds extent * self displayScale 

Scroll bars rely on a scrolling grid in which the inherited value 
for scrollGrid is 1@1.Using pasteOffset, SmallDrawView can be 
defined so that scrolling occurs in larger intervals. SmallDrawView 
provides a menu option to turn the grid on or off and SmallDraw- 
Controller uses its view’s grid for selecting points in the view. 

Opening SmallDraw with a scrolling view is done as before 
by placing the SmallDrawView in an EdgeWidgetWrapper but now 
a horizontal scroll bar is also included (see Figure 4): 

openS crolling 

"SmallDraw new openScrolling" 

ScheduledWindow new 
label: ‘SmallDraw’; 

component: (EdgeWidgetWrapper on: 

(SmallDrawView model: self)) useHorizontalScrollflar; 
openWithExtent: 200(3200 


VOSS 

Virtual Object Storage System for 

Smalltalk/V 

Seamless persistent object management 
for all Smalltalk/V applications 

• Transparent access to all kinds of Smalltalk objects on disk. 

• Transaction commit /rollback of changes to virtual objects. 
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to 4 billion objects per virtual space; objects cached for speed. 

• Multi-key and multi-value virtual dictionaries for query-building 
by key range selection and set intersection, (np) 
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• Shared access to named virtual object spaces on disk; object 
portability between images. Virtual objects are fully functional. 

• Source code supplied. 

Some comments we have received about VOSS: 

"...dean ...elegant. Works like a charm." 

-Hal Hildebrand , Anamet Laboratories 
"Works absolutely beautifully; excellent performance and 
applicability." -Raul Duran, Microgenics Instruments 

VOSS/286 $595 (Personal $199), VOSS/Windows $750 (Personal $299) 
r • (Personal versions exclude items marked (np)). 

ioaic Quantity discounts from 30% for two or more copies. (Ask for details) 
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Figure 4. Two scrolling views (25% and 100%) and two pages side by side. 


ing (e.g., a GraphicsContext subclass that outputs 
PostScript), or sharing of graphic objects with other 
Smalltalk applications. 

The complete source code corresponding to each of the 
three SmallDraw articles can be obtained from the University 
of Illinois and Manchester archives. They are identified as 
SmallDrawl, SmallDraw2, and SmallDraw3. The source code 
is available to all with no restrictions. I ask only that proper 
credit be given so that I may hear from those who have 
benefited. I also encourage those who make improvements or 
additions to SmallDraw to make them available through the 
archives for others’ education and use. ■ 


SUMMARY 

Building on the first two SmallDraw articles, this final article 
has presented further enhancements to SmallDraw to demon¬ 
strate Release 4 graphics and MVC application construction. 
Though far from perfect, it should give beginners a good start 
on their own development. 

Certainly many improvements and enhancements can be 
made to SmallDraw. New types of graphic objects, such as 
Text, Images, and Bezier curves (included in Release 4.1), 
can be added. Other object operations can be defined, such 
as rotation, smoothing of polygons, editing individual points 
on a polygon, undo, or auto scrolling of the drawing while 
translating or scaling objects beyond the extent of the view. 
Advanced functionality can be provided to allow for saving 
drawings to files, PostScript or LaTeX printing of the draw- 


Dan Benson completed his PhD in Electrical Engineering at the Uni¬ 
versity of Washington where he developed a 3-D spatial database for 
human anatomy using Smalltalk and the GemStone ODBMS. He is 
now a Research Scientist with Siemens working in the area of Image 
Management and Distribution. He may be contacted at: Siemens 
Corporate Research, Inc., 755 College Road East, Princeton, NJ 
08540, or by email: benson@siemens.siemens.com. 
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Alan Knight 


What else is wrong with OOP? 


T his might more accurately be called “What else do peo¬ 
ple on USENET think is wrong with OOP?” While there 
are certainly areas in which OOP could be improved, 
there are many misconceptions and false criticisms—so many, 
in fact, that I ran out of space for them last month and am 
continuing the topic here. 

Let’s start with one of the most common complaints: appli¬ 
cation areas for which OOP is inappropriate. 

OOP CAN’T HANDLE PROBLEMS LIKE... 

Harry Erwin (erwin@trwacs.fp.trw.com) writes: 

OOP can be a disadvantage if the problem domain does 
not lend itself conveniently to object representations. For 
example, many algorithms consist of a primary control 
loop operating on passive things, and a Pascal or Ada pro¬ 
gram of the traditional mode is more efficient and dearer. 

If true, this represents a severe restriction of the OOP do¬ 
main. Many algorithms fit the pattern of a loop operating on 
passive things; if OOP can’t handle them, most programming 
is ruled out. Objects will have to be relegated to simple GUI 
tasks, error handling, and other algorithmically trivial areas. 

In my opinion, it is not difficult to describe many algo¬ 
rithms in terms of a main loop. The loop can be written as: 

aBunchOfPassiveThings do: [:passiveThing | 
algorithmManager process: passiveThing], 

The code gets more complicated if we include initialization 
and post-processing code, or if it has to use a more complex 
method of choosing the next item, but I do not think a Pascal 
or Ada program could be dearer. 

The complicated part is the processing of each “passive 
thing," which usually consists of elaborate manipulations of 
various data structures. The algorithms literature considers it 
good form to describe these manipulations in terms of opera¬ 
tions on abstract data types. OOP usually handles abstract data 
types very well, so it is actually very good for this kind of work. 

BUT THAT’S NOT REALLY OBJECT ORIENTED 

I’m quite happy with the general method of writing “tradi¬ 
tional” algorithms using OOP because (1) the program struc¬ 
tures correspond well with typical algorithm description, (2) 
there’s good potential for reuse of abstract data type classes, 


(3) it’s clearly suitable for implementation in an OO language, 
and (4) it nicely groups together the algorithm data in the 
AlgorithmXManager class. 

A recurring theme among complaints about OOP is that it 
is “not really object-oriented.” But OOP solutions to problems 
are often rejected as not being faithful to the principles of 
object orientation because of a misguided idea of what objects 
are about. 

THE PRINCIPLES OF OOP 

What does it mean for a solution to be object-oriented? On 
what basis are these kinds of solutions rejected? Are these ideas 
valid and, if so, are they important enough to make us discard 
good solutions? 

The standard definition of an OO language says that it 
should support encapsulation, polymorphism, and inheri¬ 
tance. True, but these are language features, not a set of guid¬ 
ing principles. The dictionary is even less helpful. Mine traces 
the word object to the Latin objectum, literally meaning “some¬ 
thing thrown before or against.” Its roots are the words ob 
(against) and jacio (to throw). Since we are interested in per¬ 
ceptions of OOP, let’s find out what people on USENET think. 
David Myers (dem@meaddata.com) writes: 

Once people learn Object-Oriented Design, they seem to 
fall into two schools of thought I’m interested in your 
thoughts on which, if either, is more correct. 

The first camp I’ll call “Strict OOD.” They believe that all 
functions that need to modify some object must necessarily 
be member functions of that object.... 

The second camp I’ll call “Reality OOD.” They don’t be¬ 
lieve in taking things as far as the first camp if the resulting 
model wouldn’t fit with their perception of reality....The 
Reality OOD folks want to build an OO system so that its 
components closely represent the world they are trying to 
model.... 

and later expands: 

You want to model a cow, and want to get milk from the 
cow and put it in a vat...Strict OOD might say, “Just add a 
method ‘Cow, milk yourself,’ which puts the milk right in 
the vat. Leave the details to the cow.” Obviously, Reality 
OOD would say something different. “Cow, present ud- 
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ders. Udders are the interface here, and we can ‘pass’ a cow 
to a farmer object to get the cow milked and the milk in the 
vat. The farmer contains the knowledge of how milking 
should be done, not the cow.” 

...say we now have a better way to milk a cow, with a milk¬ 
ing machine. Strict OOD would say, “Modify the cow to 
understand how to use the milking machine...” Reality 
OOD would say, “Just ‘pass’ the cow to the new machine. 
The cow doesn’t need to change as it already provides the 
necessary interface.” 

...Another example. Say you have some glob of data, and 
you want to run N validation processes against it...Where 
do these processes go? Strict OOD, “Part of the glob, obvi¬ 
ously. That’s what they act upon.” Reality OOD, “They’re 
separate from the glob, and use whatever interface is pro¬ 
vided by the glob to do their work.” 

This is quite interesting, because it’s a well-considered, 
thoughtful posting based fundamentally on false ideas of OOP. 
It arises from the basic question of where to put methods, but 
in my opinion gets the principles wrong. I see the method 
placement question as a conflict between the principles of 
coupling and cohesion. 

Consider the validation example, which expresses this most 
clearly. A Validator class is a good idea. It groups related meth¬ 
ods (for testing) together, and removes clutter from the class 
being tested. It’s easy to add additional validation checks, and 
seems to be the only method that generalizes to consistency 
checks involving several different objects. 

On the other hand, we should hide internal representations 
to minimize coupling. The internals of a class should not be 
exposed, and we expect validation to require access to these de¬ 
tails at least some of the time. 

A good compromise is to use both techniques. Use class 
methods to implement tests that depend on internal representa¬ 
tions, preferably using a consistent naming scheme. Tests that 
can be done through the public interface should be implemented 
through a Validator class, which when validating can also invoke 
the appropriate self-testing methods in the individual class. 

The above posting is based on two false ideas, one in each 
camp. Mr. Myers presents “Strict OOD” as the orthodoxy of 
the OOP gurus. It dictates that any method modifying an ob¬ 
ject’s state must belong to the class of that object. On the sur¬ 
face this sounds reasonable, very much like encapsulation, but 
it’s an overgeneralization that simply cannot work in practice. 

Encapsulation restricts the set of methods that can access 
an object’s internal representation to those in its class. This is 
enforced in Smalltalk, but it is possible to short-circuit the re¬ 
striction by writing get/set methods for each instance variable. 
A method that accesses an object’s state through message sends 
could be placed anywhere, but if it operates primarily on one 
object it is good style to make it a method in that class. 

There’s a big difference, however, between good style and 
an enforced rule. In particular, the “strict” position does not 
allow the possibility of methods that modify (or even access) 
more than one object. This disallows such a simple thing as a 


bank transaction, where one account is incremented and an¬ 
other decremented. 

The “Reality OOD” camp allows such methods, but then 
runs back into the question of method placement, as K. Srini- 
vasan (srini@gtsurya.gatech.edu) points out: 

I am interested in developing 00 models to represent 
manufacturing enterprises. I ran into the very same prob¬ 
lem you’ve described — A method “process a part” seems 
to alter the states of the part object, the machine object and 
the operator object, and hence is a candidate for being a 
method belonging to any of them. To make it a method of 
one, say “part,” and make that object a client of other two 
objects (operator and machine) will work. However, it 
seems to be a highly arbitrary decision. 

I agree wholeheartedly. If two or more things interact, and 
the states are all changing, then the decision to place a method 
handling this interaction is arbitrary. If the interaction is 
sufficiently important, it may be worthwhile modeling it as an 
object itself. Ralph Johnson (johnson@cs.uiuc.edu) discusses 
this in the context of the milking example. 

The real issue is how to divide responsibilities among ob¬ 
jects .... Why not give the vat responsibility for taking the 
milk from a cow? Without knowing anything about the 
real world domain and what is likely to change, any of 
three possibilities is just as likely. We have a transaction 
between object C and object V, and the question is whether 
we should introduce a new object F to model the transac¬ 
tion (transactor) or we should make the transaction a 
method of C or V. In general, it all depends!...If we have a 
simple system whether nothing changes, then it might 
make sense to put the responsibility for the transaction in 
C. If we knew that the transaction itself was never going to 
change, and that C was, (i.e. we want to milk sheep, goats, 
horses, yaks, etc.) then it might be better to put it in V. If 
the transaction itself is going to change (i.e. use a milking 
machine) then it would be better to make it an object. 

Once again we hear the cry that this solution is "not really 
object-oriented,” which brings us to the second, and more im¬ 
portant, fallacy. 

OOP AND THE REAL WORLD 

Choosing the right name for something is important. A name 
should be short, easy to remember, and clearly communicate 
the essential idea. Unfortunately, “object-oriented” fails in the 
last category. 

The problem is that everyone knows what an object is. We 
intuitively “know” that object-oriented programming is all 
about objects: concrete, physical things that we can, with 
enough machinery, pick up and throw. Processes can’t be ob¬ 
jects. Relationships can’t be objects. Concepts can’t be objects. 
OOP is “good” because it writes programs that perfectly mimic 
the real world, and an OO program is “good” in direct propor¬ 
tion to its mimicry—like neural networks, which we all know 


September 1992 


15 



■ THE BEST OF COMP.LANG 


work just like human brains. Being told that OOP is good for 
simulation and that it naturally models the problem domain 
only makes these misconceptions worse. 

Smalltalk programmers tend to transcend these ideas more 
quickly than others because they’re confronted with examples of 
Schedulers, Controllers, Associations, and other non-concrete 
classes. Even so, the misconceptions are very widespread. Let’s 
look at some concrete examples. 

Objects are always concrete nouns 

Dan Weinreb (dlw@odi.com) writes: 

This topic comes up again and again whenever semantic 
data modeling is being discussed. I’ve seen it in papers from 
over ten years ago. After reading a bunch of the literature in 
this area I have come to the conclusion that there doesn’t 
seem to be any completely satisfying answer. Either you end 
up having these objects that only model relationships rather 
than modeling “things” in the problem domain, or else you 
end up inventing constructs that are annoyingly complex 
and often disturbingly similar to objects themselves. 

and Doug MacDonald (doug@softwords.bc.ca) writes: 

This thread raises what I have always considered to be a 
shortcoming of OO scheme of modeling the world: while it 
allows us to capture complex classifications and instances, 
it does NOT provide the idea of relationships among ob¬ 
jects. Yes, we can “send messages” among objects, provide 
well-structured access functions. But this does not address 
the central problem. We end up with forced concepts like 
relationship classes to deal with the cow-milk type puzzles. 

This literal interpretation of objects corresponding only to 
physical “things" is probably the single most prevalent miscon¬ 
ception about OOP. It is the main reason people reject solutions 
that include an AlgorithmManager or a class representing the rela¬ 
tionship between cows and fanners. I've seen many other exam¬ 
ples, including database discussions that assumed an ODBMS 
could model only physical things, and that an RDBMS could 
only model relationships. In a similarly literal vein. I’ve seen C 
described as a functional language because it has functions. 

Naturally, there are many who do not share these beliefs. 
Eric Smith (eric@tfs.com) writes: 

There is nothing “forced” about relationship classes. Rela¬ 
tionships are objects, period. The word “relationship” is a 
noun. A relationship object should contain references to its 
target objects, functions to return information about its 
target objects and about various aspects of the relationship 
between them, and functions to modify the relationship. 

Mike Wirth (mcw@cs.rice.edu) writes: 

Nothing unnatural about it at all. Associations between ob¬ 
jects are every bit as much “real world” objects as the objects 
being associated. Ask your spouse or “significant other.” 

And Ralph Johnson (johnson@cs.uiuc.edu), who seems to 


have encountered these ideas before, anticipated the objections 
in the same posting quoted above: 

There is NOTHING wrong with having objects that repre¬ 
sent processes. It is true that novice OO designers make a 
lot of such objects that are bad design, but good OO de¬ 
signers make those kinds of objects, too. You just need to 
have a good reason for introducing a new object. 

The fundamental point of OOP is abstraction. A good OOP 
design should correspond to ideas in the problem domain. 
Whether those happen to be ideas about things that can be 
touched or about relationships, processes, or concepts is irrele¬ 
vant. One of the best metrics for this is naming. If someone fa¬ 
miliar with the domain can look at a class name and immedi¬ 
ately have some idea what it does, then it’s probably a good 
class for that domain. 

There is exactly one “right" OOP design for a problem 

Given that the objective is a perfect model of reality, then all 
OO designs should converge. After all, there’s only one real 
world. This results in much disappointment when people dis¬ 
cover that OOP, like any other kind of programming, still has 
design decisions and trade-offs. 

David A. Hasan (hasan@ut-emx.uucp) writes: 

...the “map” between OO methods/objects and what is go¬ 
ing on in the real world is NOT unique. There can be 
different interpretations on which objects should carry out 
which methods based on how the real world activities are 
“best modeled.” Therefore a choice must be made in speci¬ 
fying object interfaces and making this choice might un¬ 
duly constrain future versions of the system... 

This is entirely true, but it is based on vastly inflated expecta¬ 
tions of what OOP can do. 

bobm@Ingres.COM (Bob McQueer) replies: 

What problem you are trying to solve defines “proper,” I 
think. I can see us having the same problems we have al¬ 
ways had when trying to “grow” new functionality into a 
design that didn’t anticipate growth in that direction. Note 
that expediency will dictate that you can’t make provisions 
for EVERY possible direction of growth, also as it always 
has.... I think what I’m saying is that while the OO 
paradigm is a useful tool, you can’t expect the existence of 
a paradigm to do all your work for you. There is NOT a 
unique map, and it takes proper use of the tool to define 
the map which serves your purposes. 

THE REAL WORLD AGAIN 

The idea of modeling the real world in detail is fallacious. In 
what we call “reality,” most things are human-imposed con¬ 
cepts. Reality consists mostly of interactions between elemen¬ 
tary particles; the higher-level structures we perceive are ab- 

continued on page 22... 
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ETTING REAL 


Juanita Ewing 


Extending the Collection hierarchy 


I n my last column, I discussed creating subclasses and two 
heuristics for selecting superclasses. This month I will con¬ 
tinue the discussion on subclassing with a case study that 
extends the Collection hierarchy. We will create a new Collection 
class that contains unique elements and also maintains the or¬ 
der of these elements. 

HEURISTICS REVIEW 

A key step in creating a new subclass is to select a suitable su¬ 
perclass. The heuristics for selecting a superclass are: 

Heuristic One. Look for a class that fits the is-kind-of or 
is-type-of relationship with your new subclass. 

Heuristic Two: Look for a class with behavior that is similar 
to the desired behavior of the new subclass. 

CASE STUDY 

We want to create a new data structure class that holds ele¬ 
ments in order and disallows duplicate elements. When sent a 
request to add a duplicate object, the request should be quietly 
ignored. 

This new data structure class contains elements similar to 
Arrays, Strings and other Collection subclasses. Because of these 
similarities, we will begin our search for candidate superclasses 
in the Collection hierarchy. Two classes immediately stand out: 
• OrderedCollections keep elements in order. 

• Sets store each element only once, disallowing duplicate 
elements. 

The combination of these characteristics is what we want 
for our new class. A good descriptive name for our new class is 
OrderedSet. 

APPLY HEURISTICS 

Where should we insert our new class, OrderedSet, into the hier¬ 
archy? Our first heuristic is to look for potential superclasses 
that match the is-kind-of criteria. We use is-kind-of as a short¬ 
hand for categorization based on characteristics. The significant 
characteristics and their classes used in this determination are: 

• vary number of elements (Collection) 

■ store arbitrary objects (Collection) 

• dynamically add and remove elements (Collection) 

• enumerate (Collection) 


■ store elements in order (OrderedCollection) 

■ store unique elements (Set) 


The desired characteristics of OrderedSet are closest to those 
of OrderedCollection and Set, so OrderedSet could be a-kind-of 
Set or a-kind-of OrderedCollection. 

In a system that supports multiple inheritance, we might be 
tempted to have two superclasses, Set and OrderedCollection. In 
Smalltalk we must choose a single superclass, either Set or Or¬ 
deredCollection. 

Our second heuristic is to choose candidate superclasses with 
suitable public behavior. Let’s compare the candidate classes 
we’ve selected, Set and OrderedCollection, in terms ofbehavior. 
Set and OrderedCollection have a common superclass, Collection, 
so we can ignore public behavior from the Collection on up. 

If we were to make OrderedSet a subclass of Set, it would in¬ 
herit these methods from Set: 

add: 

do; 

includes: 

occurencesOf: 

remove:i£Absenb 

size 


All of these methods also have an implementation in the 
abstract superclass Collection, so Set doesn’t add any new public 
behavior to the behavior from the common superclass. 

If OrderedSet were a subclass of OrderedCollection, it would 
inherit behavior from OrderedCollection and IndexedCollection 
(or OrderedCollection and SequencableCollection in Object- 
works! Smalltalk). OrderedCollection has adding and removing 
methods and many more methods related to its element¬ 
ordering characteristic. The list of methods includes: 


add: 

add: after: 
add:afterlndex: 
add:before: 
add:beforeIndex: 


addfirst: 
addlast: 

remove:ifAbsent: 
removeFirst 
removeLast 


Many of these methods are extensions of the public behav¬ 
ior from the common superclass Collection. 

The public behaviors for Sets and OrderedCollections have 
some similarities. In fact, the behavior of Set is a subset of the 
behavior of OrderedCollection, which makes Set the behavioral 
supertype of OrderedCollection. Set doesn’t add any additional 
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behavior, so we just need to determine whether the additional 
behavior in OrderedCollection is desirable. 

Because instances of OrderedSet maintain elements in order, 
we will need public behavior to support the ordering charac¬ 
teristic. The behavior in OrderedCollection is a good set of be¬ 
havior for supporting this characteristic. In addition, if the be¬ 
havior of OrderedSet is the same as for OrderedCollection, the 
interchangeability of the classes is better and therefore the 
classes are easier to reuse. Based on behavioral analysis, the 
best superclass for OrderedSet is OrderedCollection. 

IMPLEMENTATION 

We can also look in more detail at what is required to imple¬ 
ment OrderedSet. The implementation of OrderedCollection uses 
an indexable portion or indexable object, as well as instance 
variables to keep track of valid indices, Set is implemented with 
hashing for efficiency in determining uniqueness of elements. 
If a Set already contains an element, it quiedy ignores the re¬ 
quest to add an element. 

OrderedSet needs to support instances with a large number 
of elements. Hashing the elements is a good way to support 
large numbers. OrderedColIections would potentially have to ex¬ 
amine every element before determining if the addition of an 
element would be a duplication. To maintain order and en¬ 
force uniqueness we will use two structures, one to implement 
the unique elements characteristic, and one to implement the 
ordering characteristic, as shown in Figure 1. 



Now we will examine the implementations with each of our 
candidate superclasses. If OrderedSet is a subclass of OrderedCol¬ 
lection, we inherit the portion that stores elements in order and 
we need to implement the portion that hashes and enforces 
uniqueness. The structure and behavior for maintaining order 
is inherited from OrderedCollection, and the structure for en¬ 
forcing uniqueness can be stored in an instance variable. This 
structure could be an instance of Set. 

With this alternative, some inherited methods would need 
to be overridden. All the add and remove methods must po¬ 
tentially be altered to maintain both structures. As seen in the 
list of public behavior, there are a number of these methods, 
such as add:, add:aiter:, add;afterlndex:, addfirst:, removefirst and 
removeLast. Fortunately, not all these methods have to be over¬ 


ridden because some of them call each other. We would want 
to override includes: because the hashing used in the unique¬ 
ness structure gives us a quick lookup of elements. We would 
not override do: because it operates on the inherited structure 
that maintains order. 

If OrderedSet were a subclass of Set, the inherited structure 
is the one that enforces uniqueness; an auxiliary structure for 
maintaining order is referenced from an instance variable. Pre¬ 
sumably, the order maintaining structure would be an instance 
of OrderedCollection. 

We would also need to override adding and removing 
methods—there is just one of each. The majority of coding is 
in implementing behavior that implements the element order¬ 
ing characteristic. We would not need to override includes: be¬ 
cause we inherit the version that makes use of hashing, but we 
would need to override do: so that we process elements in the 
ordered defined by the order maintaining structure. 

NAMING 

Other criteria that might bias our judgment are implications of 
a class’s name. If a class hierarchy is part of the public interface 
for a library, it might be easier for users to locate a class located 
in a logical place in the hierarchy. With a class called Ordered¬ 
Set, users are more likely to look for this class as a specializa¬ 
tion of Set. They might not find it as easily if it is a subclass of 
OrderedCollection. 

CONCLUSION 

We make OrderedSet a subclass of OrderedCollection because: 

■ The behavior of OrderedCollection is more suitable than the 
behavior of Set. 

■ It is more likely that the behavior will be interchangeable if 
the relationship between the two classes is explicit. 

■ There are fewer methods, overridden and new, that must be 
implemented in OrderedSet. 

Furthermore, by browsing the Collection hierarchy, develop¬ 
ers will generally examine several Collection classes at a time, and 
will probably notice OrderedSet as a subclass of OrderedCollection. 

The is-kind-of heuristic is useful for generating candidate 
superclasses. Its intuitive nature can be an advantage. How¬ 
ever, analysis of public behavior often yields a better selection. 
If we only used the is-kind-of heuristic in our case study, we 
would be most likely to make OrderedSet a subclass of Set. On 
the other hand, when we use the public behavior heuristic, we 
conclude that OrderedCollection is a better choice. Ill 
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vices (formerly Instantiations Inc.). She has been a project leader for 
several commercial 0-0 software projects, and is an expert in the de¬ 
sign and implementation of 0-0 applications, frameworks, and sys¬ 
tems. In a previous position at Tektronix Inc., she was responsible for 
the development of the class libraries for the first commercial-quality 
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IDIOMS 


ValueModel idioms 


Kent Beck 


M y last column outlined ways of using dependency as 
embodied in Smalltalk’s update and changed mes¬ 
sages. ParcPlace’s release 4 of Objectworks\Smalltalk 
introduced a significant refinement of dependency called Val- 
ueModel which addresses some of the shortcomings of the 
classic style of dependency management. 

CLASSIC SMALLTALK STYLE 

Here is another example of the classic style of Smalltalk change 
propagation. A Mandelbrot renders a portion of the Mandelbrot 
set while it measures performance. 

Mandelbrot 

superclass: Model 
instance variables: region flops 

A Mandelbrot object renders the portion of the Mandelbrot 
set in region (a Rectangle with floating point coordinates) on 
an Image when sent displayOn:. Assume we have implemented 
a primitive rendering method that returns the number of float¬ 
ing point operations it initiates as it displays. The DisplayOn: 
method divides the number of operations by the rendering 
time to compute the number of floating point operations per 
second, which will be stored in flops. 

displayOn: anlmage 
| time ops | 

time := Time millisecondsToRun: 

[ops := self prim DisplayOn .-anlmage]. 
self flops: ops / time / 1000 

The model responds to openflops by creating a window that 
displays the value of flops. 

openflops 
| window | 

window := ScheduledWindow new. 
window addChild: (TextVIew on: self aspect: #flopsString 
change:nil menu: nil) 
window open 

Some users complain that putting an open method in the 
model allows too much of the interface to leak through. But in 
my opinion one is free to open any kind of window, and if the 
model offers a default way, so much the better. Putting open in 
the model keeps the code together; if more flexibility is needed 
later it can always be moved. 

TextView’s symbol flopsStiing is used by the view both to rec¬ 
ognize an interesting broadcast and as a message to the model 


to return a string suitable for viewing. The model thus needs to 
respond to flopsStiing. 

flopsString 

"self flops piintString, 'flops' 

Now all that remains to update the view is to propagate a 
change whenever the flops change. 

flops: aNumber 
flops := aNumber. 
self changed: #flopsString 

Already the interface is beginning to leak into the model. Be¬ 
cause the example interface uses the symbol #flopsString, the 
model must have this particular symbol built in. Other interfaces 
viewing other aspects of the model dependent on the measured 
flops will require additional broadcasts when the flops change. 

The model is no longer insulated from changes to the interface. 

Let’s refine the model a bit to see where this style of change 
propagation begins to fall apart. What if instead of displaying 
the last value of flops we want to display the average of recent 
values? flops holds an OrderedCollection instead of a Number. 

initialize 

flops := OrderedCollection new 

The setting method adds to the collection instead of chang¬ 
ing the instance variable. 

flops: aNumber 

flops addLast: aNumber. 
self changed: #ftopsString 

The accessing method has to compute the average instead 
of just returning the value. 

flops 

flops isEmpty ifTrue: ["float zero]. 

"(flops inject: float zero into: [:sum :each [ sum + each]) 

/ flops size 

The above code is still fairly clean from an implementation 
perspective. From a design standpoint, though, it is a danger¬ 
ous path. 

The first problem is that the needs of the interface influence 
our implementation of the model. Conversely, our concept of 
an interface is constrained by the way we have implemented 
the model. The separation of model from interface, supported 
at the implementation level by broadcasting changes, merely 
reappears as a design problem. In other words, the letter of 
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“separate model and interface” is satisfied because the model 
makes no direct reference to the interface, but the spirit is vio¬ 
lated because interface decisions have caused us to change a 
model that should be oblivious to such concerns. 

Other views with other aspects require inserting more hard¬ 
wired broadcast messages. In large projects, this process of 
broadcast accretion leads to a bewildering profusion of broad¬ 
casts, often with intricate time dependencies. 

Another problem is that this style of programming discour¬ 
ages reuse. Each instance variable is a special case, to be handled 
by special case code. For example, suppose we are working in a 
multiprocessor environment and want to view a running aver¬ 
age of the number of processors active during rendering. We 
could add an instance variable, utilization, with accessing and 
setting methods that are copies of the respective messages for 
flops, but we could do no better at reuse than copy and paste. 

This last point suggests that state change and change propaga¬ 
tion somehow must be folded together into a new object This ob¬ 
ject will be used instead of a bare instance variable as a model for 
views. We can create a family of these objects to model the differ¬ 
ent ways of viewing state changes over time. By using various 
kinds of objects in varying circumstances we can change the inter¬ 
action supported by the model without changing the model itself. 

The most common solution to these problems is to separate 
the model into a “browser” object and a clean underlying 
model without broadcasts (see Figure 1). The browser medi¬ 
ates between the user interface and the “real” model, translat¬ 
ing user requests into messages to the model and propagating 
changes back to the interface. Although fairly simple conceptu¬ 
ally, this style of programming introduces another layer of ob¬ 
jects between the user and the model without addressing the 
problem of multiple browsers on the same model (for exam¬ 
ple, the problem of updating the source code of a method ap¬ 
pearing in more than one Browser). 

VALUE MODEL STYLE 

ValueModels in Objectworks\Smalltalk Release 4 fill the role of 
an interaction model. Rather than appearing between the do¬ 
main model and the interface, ValueModels are placed “be¬ 
neath” the domain model. This allows the view to interact di¬ 
rectly with the state of the domain model and does not clutter 
the model itself with interaction concerns. 

Here’s how an ideal implementation can be applied to our 
example: 


ValueModel 

superclass: Model 
instance variables: value 

value 

"value 

value: anObject 
value := anObject 
self changed: #value 

We can recast Mandelbrot to use this simple ValueModel. 
First, the initialization method sets flops to a ValueModel. 

initialize 

flops := ValueModel new 

When accessing or setting the value you must remember to 
send messages to flops and not just use the instance variable. 
Religious use of accessing and setting methods, though, can 
hide this detail from the rest of the object. 

flops 

"flops value 

Note that when the value is set the Mandelbrot no longer 
needs to propagate changes. 

flops: aNumber 

flops value: aNumber 

When making a view to display flops the ValueModel is the 
model of the TextView, not the Mandelbrot. 

openflops 
| window | 

window := ScheduledWIndow new. 
window addChild: (TextView on: flops aspect: #value 
change: nil menu: nil), 
window open 

We now have a system with the same functionality as the 
simplest one described above. Figure 2 diagrams the relation¬ 
ships between the various components in the value model-style 
Mandelbrot. 

The worth of ValueModels becomes apparent when we dis¬ 
play a running average rather than a single value. The change is 
made creating a subclass of ValueModel called AveragingValue- 
Model, which accumulates a history of values in response to 
value:messages. 

AveragingValueModel 
superclass: ValueModel 
instance variables: none 



Figure I. Classic separation of model and interface. 
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initialize 

value := OrderedCoUection new 
value 

value isEmpty iJTrae: [ A Float zero]. 

"(value inject: Float zero into: [:sum :each | sum + each]) 

/ value size 
value: anObject 

value addLast: anObject 

We can install the new behavior by changing 
MandeUirot»initialize. 
initialize 

flops := AveragingValueModel new 

No other changes to the model are necessary. When we want 
to open a window on a running average of processor utiliza¬ 
tion we can create another AveragingValueModel. We do not 
need to duplicate any code. 

The model has acquired a large measure of independence 
from changes mandated by the interface. For many interface 
changes we no longer need to touch code in the domain model 
beyond modifying the initialization. We instantiate a new kind 
ofValueModel and the rest of the model remains unchanged. 

THE REST OF THE STORY 

The above code still doesn’t quite work. The TextView expects a 
String or a Text from its model, and the ValueModel in this case 
returns a Number. The release 4.1 solution is to interpose an¬ 
other object, called a PluggableAdaptor, between the model and 
the view. A PluggableAdaptor contains three blocks. The first is 
invoked when it receives the message value. The block takes one 
argument, the adaptor's model (in this case the ValueModel), 
and by default returns the result of sending value to the model. 
The block can be used to arbitrarily transform the value. In our 
case we want to create a string from the number: 

openflops 

| window adaptor | 
window :■ ScheduledWindow new. 
adaptor :=* AspectAdaptor on: flops, 
adaptor getBlock: [:m | m value printstring,' flops'], 
window addChxUL (TextView oru adaptor aspect: #value 
change: nil menu: nil), 
window open 

The second block in a PluggableAdaptor is evaluated when 
the adaptor receives the value: message. The block is invoked 
with the model and the new value as arguments. By default it 
passes the message along to the model. This block translates 
the value from a form the view understands to one the model 
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understands. If it was possible to change the flops rating, we 
might write something like this: 


openflops 

| window adaptor | 

window :■= ScheduledWindow new. 

adaptor := AspectAdaptor on: flops. 

adaptor getBlock: [:m | m value printstring, 'Aops']. 

adaptor putBlock: [:m :v | 

m value: (Number readFrom: v readStream)]. 
window addChild: (TextView on: adaptor aspect: #value 
change: nil menu: nil), 
window open 

The final PluggableAdaptor block is used to filter update 
messages. The block takes three arguments: the model, the as¬ 
pect from the update: message, and the optional parameter 
from the update: message. The block evaluates to a boolean 
that is used to decide whether or not to forward the update. In 
our example we may not want to update the text if the flops 
rating is too low. We could change openflops as follows: 

openflops 

| window adaptor | 
window :• ScheduledWindow new. 
adaptor :■= AspectAdaptor on: Aops. 
adaptor getBlock: [;m | m value printstring,' flops'], 
adaptor putBlock: [:m nr | m value: (Number readFrom: v 
readStream)]. 

adaptor updateBlock: [:m :a :p | m value > le6). 
window addChild: (TextView on: adaptor aspect: #value 
change: nil menu: nil), 
window open 

When an object is dependent on two or more ValueModels it 
is often important to distinguish which one is generating the 
broadcast message. One solution is to take advantage of the full 
generality of the update message: 

A cleaner solution is to use the update block of a pluggable 
adaptor to generate different updates for each ValueModel. The 
initialization would look like this: 

initialize With: mo dell with: modelz 
| adaptorl adaptor2 | 
adaptorl :■= PluggableAdaptor on: raodell. 
adaptorl updateBlock: [:m :v :p | v *» #value 
ifTrue: [adaptorl changed: #valuel]]. 
adaptorl addDependent: self. 
adaptor2 :* HuggableAdaptor on: model2. 
adaptor? updateBlock: [an w :p | v “ #value 
ifTrue: [adaptorlchanged: #value2]]. 
adaptor2 addDependent: self 

Then the update method can look like this: 
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■ ValueModel idioms 


update: aSymbol 

aSymbol == #valuel ifTme: [self updateValuel]. 

aSymbol == #value2 ifTme: [self updateValue2] 

The preceding information is written assuming ValueModel 
holds values. In the real system, though, ValueModel is an ab¬ 
stract superclass, and the subclass acting as ValueModel above is 
really called ValueHolder. PluggableAdaptor is also a subclass of 
ValueModel. Other subclasses (like AveragmgValueModel) should 
arise as the full utility of the ValueModel style becomes apparent. 

LAZY VIEWS 

A final idiom that accompanies Objectworks\Smalltalk release 4 
and later is lazy updating of views. Back when dinosaurs ruled 
the earth and Smalltalk did its own window management, it was 
common to directly redisplay a view in response to an update: 
update: aSymbol 

(self interestedln: aSymbol) ifTme: [self displayView] 

A serious problem with this strategy is that the view will be 
redisplayed several times if multiple update messages come in. 
Multiple updates look bad and slow your programs down. This 
is especially true with the expanded use of broadcast messages 
in release 4. 

When you implement views in release 4 and later, you 
should never directly redisplay the view. Instead the view 
should send itself an invalidate message: 


update: aSymbol 

(self interestedln: aSymbol) ifTme: [self invalidate] 

These invalidations are pooled together. The next time a 
Controller sends itself poll (or someone explicitly sends check- 
ForEvents to ScheduledControllers) all views with some invalid 
area will be asked to display. This ensures that if there is a 
change to a model causing several views to update they will re¬ 
display as simultaneously as possible. 

CONCLUSION 

The ValueModel style of coding manages complexity by strictly 
separating interface and model. 

We have just begun to explore the range of possibilities in¬ 
herent in the ValueModel style. You can expect to discover new 
uses as you begin using it yourself. If you find new ValueModels, 
or new uses for the existing ones, please drop me a line so I can 
publish them here. H 


Kent Beck has been discovering Smalltalk idioms for eight years at 
Tektronix, Apple Computer, and MasPars Computer. He is also the 
founder of First Class Software, which develops and distributes re¬ 
engineering products for Smalltalk. He can be reached at First Class 
Software, P.O. Box 226, Boulder Creek, CA 95006-0226 


THE BEST OF...continuedfrom page 16 

stractions useful in some specific domains. Reality can have 
very poor software engineering principles. 

Jeff Alger (alger@applelink.apple.com) writes: 

Seldom are you ever modeling the real world in software. 
The real world is the problem; why would you want to just 
simulate it? Objects and classes in a piece of software are 
nothing more than metaphors. In fact, direct simulations 
of real-world objects lead to very poor object-oriented ar¬ 
chitectures with little or no modularity and that are highly 
unstable. Early on one leams that a Paycheck object should 
print itself and a Block object should move itself around on 
a screen. This is not the real world. 

And Philip Santas (santas@inf.ethz.ch) points out: 

There is no such thing as information hiding in the real 
world. 

CONCLUSIONS 

Since this column has been devoted to what's wrong with OOP, 
I ought to conclude with what I think is right: 

1. OOP is not a panacea. OOP is good for improving reuse; it 
does not make reuse automatic. If I write a Car class for 
modeling traffic flow and you write a Car class for modeling 
the physics of collisions, our chances of being able to use 


the same class are small. Programs should carefully choose 
what they’re trying to model. 

2. Don’t try to model the real world in detail. Make appropri¬ 
ate abstractions, try to make your classes correspond to sen¬ 
sible entities, but don’t get caught up in the question of 
whether or not something is an object. If it makes sense as a 
concept, it’s probably a reasonable object. Good software 
engineering is more important than good modeling. 

Fundamentally, the difference between OO and procedural 
programming lies in what entities are most important. In a 
procedural language, procedures are the important thing, and 
data is secondary. The basic insight of OOP is that many func¬ 
tions can be expressed as operations on a data type, and that 
this clarifies the design. 

Other benefits spring from this insight. Using polymorphism 
we can dynamically select semantically similar operations on 
different data types, and specify data types using inheritance for 
incremental modification. The essential idea is to place the data 
type at the center. But not everything fits neatly into this model, 
and it’s not the ultimate answer to all programming problems: it 
is only an improvement on the preceding model. HI 


Alan Knight is a researcher in the Department of Mechanical and 
Aerospace Engineering at Carleton University, Ottawa, Canada, K1S 
5B6. He can be reached at +1 613 788 2600 x5783, or by e-mail as 
knight@mrco.carkton.ca. 
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P RO D UCT ANNO UNGEM ENTS 


Product Announcements are not reviews. They are abstracted from press releases provided by vendors, and no endorsement is implied. Vendors interested in being 
included in this feature should send press releases to our editorial offices, Product Announcements Dept., 91 Second Ave., Ottawa, Ontario K1S 2H4, Canada. 


The American Information Exchange Corp. (AMIX), a 

subsidiary of Autodesk Inc., announced the opening of the first 
of several key online markets for information and consulting 
services. At the AMIX Smalltalk Components and Consulting 
Market customers can buy and sell Smalltalk/V, Smalltalk-80, 
and other object code as well as consulting and training ser¬ 
vices. AMIX establishes transaction rules, facilitates negotia¬ 
tions, and automates payments and collections. 

For more information, contact AMIX, 1881 Landings 
Drive, Mountain View, CA 94043-0848,415.903.1000. 

Digitalk Inc. has announced a new version of Smalltalk/V for 
Windows that simplifies the complex task of writing programs 
for Microsoft’s popular Windows environment. 

The new version of Smalltalk/V includes support for Win¬ 
dows Multiple Document Interface (MDI), a ToolPane (a row 
of buttons that perform functions when selected), a StatusPane 
that displays information on the status of applications, an Ob- 
jectFiler for sharing objects with other applications and develop¬ 
ers, HelpManager support for non-US character sets, and per¬ 
formance improvements. In addition to standard Smalltalk/V 
features, the package provides interfaces to Dynamic Data Ex¬ 


change (DDE), allowing information to be shared between 
Smalltalk/V programs and other programs, and Dynamic Link 
Libraries (DLLs), which provide a mechanism for calling code 
written in other languages from within Smalltalk/V. 

For more information, contact Digitalk Inc., 9841 Airport 
Boulevard, Los Angeles, CA 90045, 310.645.1082, fax 
310.645.1306. 

Zoom (Zippy Object-Oriented Memory) is a simple 
object-oriented database written in Smalltalk/V for the 286, Win¬ 
dows, PM, and Mac platforms. Zoom offers variable length keys 
for random access messages at:, at:put:, removeKey: and seqeun- 
tial messages do:, first, next, prior, and last. A size method is 
available and class method open: starts any database file while 
new: guarantees a new file. Zoom works best by providing 
keyed access to Digitalk Loader/Dumper object representation, 
but an alternative representation requiring programming is 
supplied. References between filed objects must be made by 
name in your application. 

For more information, contact Expertek, P.O. Box 611, 
Clatskanie, OR 97016, 503.325.4586. 


HIGHLIGHTS 


Excerpts from industry publications 


SMALLTALK 

... If Smalltalk is so powerful, why does it have such a small 
following compared with C++? Dan Shafer, author of the 
book Practical Smalltalk, suggests that Smalltalk is so com¬ 
pletely different from any other development environment 
that the first reaction of procedural programmers is 
panic...Smalltalk’s classes and methods are not just a class li¬ 
brary but an integral part of its environment that makes up 
Smalltalk. Everything interacts with everything else. This can 
be quite disconcerting for the beginner, and the fear of break¬ 
ing something can often serve as the greatest deterrent to 
learning Smalltalk...Ultimately, we return to the original 
question: Why Smalltalk? Because you want an environment 
built around object-oriented programming, not derived from 
procedural programming. You want an environment that 
provides extensibility while managing your code. You want 
the flexibility of an interpretive language in which you can 
play with and test your code, coupled with the performance 
of a compiler. You want an interactive debugging environ¬ 
ment that lets you inspect and modify your code and vari¬ 
ables on the fly with instant results, instead of saving, compil¬ 
ing, and linking between changes. 

Why not Smalltalk? William Scott Herndon, 
UNIX REVIEW, 5/92 


PREDICTIONS 

... The object-oriented programming revolution may be the 
beginning of the biggest programming advance in the history 
of computers. It may prove to be the software equivalent of the 
microprocessor, allowing the mass creation of more capable, 
less expensive software. We say “may” simply because it may 
also be that object-oriented programming is just the beginning 
of that revolution and will itself be swept away in a compara¬ 
tively short time by the new technologies it makes possible 
Object-oriented methodology, OPEN SOFTWARE JOURNAL, vol.SIno. I 1992 

STRATEGIES 

... Robert E. Lee said “Plan no more than necessary.” His ulti¬ 
mate defeat was probably due more to the implementation of 
this philosophy than its validity. The problem in development, 
again, as in war, is how to know when to stop planning and 
start moving. The answer is never stop planning but never let 
planning prevent progress. The best methods today facilitate 
iterative development. Use one with object-oriented tech¬ 
niques for the appropriate tasks to get the most powerful and 
complete approach available. 

Planning, lookoheod,and spiraling into control, Adrian Bowies, 
OBJECT MAGAZINE /-d/92 
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WINDOWS AD OS/2: 
PROIMPE TO DELIVERY. 
NO WAITING. 

In Windows and OS/2, you need prototypes. You have to get a sense 
for what an application is going to look like, and feel like, before you can write 
it. And you can’t afford to throw the prototype away when you’re done. 

With Smalltalk/V you don’t. 

Start with the prototype. There’s no development system you can buy 
that lets you get a working model working faster than Smalltalk/V 

Then, incrementally, grow the prototype into a finished applica¬ 
tion. Try out new ideas. Get input from your users. Make more changes. 

Be creative. 


KEY FEATURES 


I World’s leading, award-winning object- 
oriented programming system 
I Complete prototype-to-delivery system 
I Zero-cost runtime 


I Simplified application delivery for 
creating standalone executable (.EXE) 
applications 

■ Code portability between Smalltalk/V 
Windows and Smalltalk/V PM 


■ Wrappers for all Windows and OS/2 
controls 


■ Support for new CUA VI controls for 
OS/2, including drag and drop, booktab, 
container; value set, slider and more 


■ Transparent support for Dynamic Data 
Exchange (DDE) and Dynamic Link 
Library (DLL) calls 

■ Fully integrated programming environ¬ 
ment, including interactive debugger, 
source code browsers (all source code 
included), world’s most extensive Win¬ 
dows and OS/2 class libraries, tutorial 
(printed and on disk), extensive samples 

■ Extensive developer support, including 
technical support, training, electronic 
developer forums, free user newsletter 

■ Broad base of third-party support, 
including add-on Smalltalk/V products, 
consulting services, books, user groups 


Smalltalk/V gives you the freedom to experiment without risk. It’s 
made for trial. And error. You make changes, and test them, one at a time. 
Safely. You get immediate feedback when you make a change. And you can’t 
make changes that break the system. It’s that safe. 

And when you’re done, whether you’re writing applications for 
Windows or OS/2, you’ll have a standalone application that runs on both. 
Smalltalk/V code is portable between the Windows and the OS/2 versions. 
And the resulting application carries no runtime charges. All for just 
$499.95. 

So take a look at fWT 

Smalltalk/V today. It’s time to make 
that prototyping time productive. 



This Smalltalk/V Windows application 
captured the PC Week Shootout award—and 
it was completed in 6 hours. 


Smalltalk/V is a registered trademark of Digitalk, Inc. Other product names are trademarks or registered 
trademarks of their respective holders. 

Digitalk, Inc., 9841 Airport Blvd., Los Angeles, CA 90045 
(800) 922-8255; (213) 645-1082; Fax (213) 645-1306 


LOOK WHO'S TALKING 


HEWLETT-PACKARD 

HP has developed a network trouble¬ 
shooting tool called the Network Advisor. 
The Network Advisor offers a comprehen¬ 
sive set of tools including an expert system, 
statistics, and protocol decodes to speed 
problem isolation. The NA user interface is 
built on a windowing system which allows 
multiple applications to be executed 
simultaneously. 


NCR 

NCR has an integrated test program develop¬ 
ment environment for digital, analog and 
mixed mode printed circuit board testing. 

MIDLAND BANK 

Midland Bank built a Windowed Technical 
Trading Environment for currency, futures 
and stock traders using Smalltalk V. 



Smalltalk/V PM applications are used to 
develop state-of-the-art CUA-compliant 
applications—and they're portable to 
Smalltalk/V Windows. 





































